This commit adds support for restoring global indexes during incremental
restore operations, extending the existing table-only restore functionality.

Key changes:

1. Index Discovery (DiscoverAndCreateIndexRestoreOperations):
   - Scans __ydb_backup_meta/indexes directory in backup
   - Discovers index backups for each table
   - Validates OmitIndexes flag from backup config

2. Index Restore Operations (CreateSingleIndexRestoreOperation):
   - Creates parallel restore operations for index implementation tables
   - Validates indexes exist on target tables
   - Filters for EIndexTypeGlobal indexes only (matches backup behavior)
   - Tracks operations same as table operations for unified completion

3. Path Mapping (FindTargetTablePath):
   - Maps relative backup paths to target table paths
   - Uses backup collection's ExplicitEntryList for mapping

Architecture:
- Tables and indexes restore IN PARALLEL (no artificial dependencies)
- Both tracked in same InProgressOperations set
- Atomic activation when ALL operations complete (via existing finalization)
- Gracefully handles missing indexes and OmitIndexes flag

The implementation reuses existing restore operation types and tracking
mechanisms, requiring no changes to proto definitions or finalization logic.

Related to: feature/incr-backup/indexes-support-003

This commit adds 5 comprehensive test cases covering all aspects of
incremental restore for global indexes:

1. BasicIndexIncrementalRestore:
   - Tests single global index restore
   - Verifies index functionality after restore
   - Tests querying via index after restoration

2. MultipleIndexesIncrementalRestore:
   - Tests table with 3 global indexes
   - Verifies all indexes restore correctly
   - Validates parallel index restore functionality

3. IndexDataVerificationIncrementalRestore:
   - Multi-shard table with index
   - Tests INSERT, UPDATE, DELETE operations across shards
   - Verifies index data integrity after restore
   - Compares before/after restore index query results

4. MultipleIncrementalBackupsWithIndexes:
   - Tests sequence of 3 incremental backups
   - Each backup has different operations (add, update, delete)
   - Verifies indexes restored correctly across all increments

5. MultipleTablesWithIndexesIncrementalRestore:
   - Tests backup collection with 2 tables
   - Each table has different global index
   - Verifies parallel restore of multiple table+index combinations

Test Coverage:
- Basic index restore ✓
- Multiple indexes per table ✓
- Multi-shard index tables ✓
- Index data verification ✓
- Multiple incremental sequences ✓
- Multiple tables with indexes ✓
- Parallel completion ✓ (implicitly tested in all tests)
- Index queries after restore ✓

Total: 506 lines of test code added

Enhanced all 5 index restore tests to directly query index implementation
tables, providing stronger verification that indexes are correctly restored.

Changes per test:

1. BasicIndexIncrementalRestore:
   - Query indexImplTable directly to verify structure
   - Count rows in index impl table (should be 4)
   - Verify specific indexed_col values (100, 250, 300, 400)

2. MultipleIndexesIncrementalRestore:
   - Query all 3 index impl tables (index1, index2, index3)
   - Verify row counts for each (all should have 4 rows)
   - Spot-check index3 impl table data

3. IndexDataVerificationIncrementalRestore:
   - Query age_index impl table directly
   - Verify correct data after INSERT/UPDATE/DELETE operations
   - Confirm deleted records NOT in index impl table
   - Verify row count (should be 4 after deletions)

4. MultipleIncrementalBackupsWithIndexes:
   - Query idx impl table after 3 incremental backups
   - Verify old values removed (100, 200)
   - Verify new/updated values present (250, 300, 400)
   - Confirm final row count (should be 3)

5. MultipleTablesWithIndexesIncrementalRestore:
   - Query both idx1 and idx2 impl tables
   - Verify row counts for both (should be 3 each)
   - Spot-check data in both index impl tables

Benefits:
- Stronger verification that index tables were actually restored
- Tests verify index table structure is intact
- Validates index data matches expected state
- Ensures index impl tables are queryable after restore
- Confirms parallel restore of multiple indexes

Pattern used: `/Root/{table}/{index}/indexImplTable`
Key insight: Index columns appear first, then main table key columns

Total: +98 lines of enhanced test verification

Addresses two critical PR review comments:

1. Fix nested table path discovery (CRITICAL BUG):
   - Previous: Only looked 1 level deep in __ydb_backup_meta/indexes/
   - Impact: Tables in subdirectories (e.g. /Root/Dir/Foo) had indexes silently skipped
   - Fix: Implemented recursive DiscoverIndexesRecursive() that:
     * Traverses the full directory tree under indexes/
     * Accumulates relative path as it descends (Root -> Root/Dir -> Root/Dir/Foo)
     * Matches against target tables at each level
     * Creates index operations when match found

   Example:
     Backup structure: __ydb_backup_meta/indexes/Root/Dir/Foo/index1
     Old behavior: Only saw "Root", failed to match, skipped all indexes
     New behavior: Descends to "Root/Dir/Foo", matches table, restores indexes

2. Fix path matching to prevent false positives:
   - Previous: itemPath.EndsWith(relativeTablePath)
   - Problem: /Root/FooBar matched "Bar", /Root/users_table matched "table"
   - Fix: Only accept exact match OR suffix preceded by "/"
     * itemPath == relativeTablePath
     * itemPath.EndsWith("/" + relativeTablePath)

Changes:
- Added DiscoverIndexesRecursive() helper for recursive directory traversal
- Updated FindTargetTablePath() to use exact matching logic
- Updated DiscoverAndCreateIndexRestoreOperations() to call recursive helper

Files modified:
- schemeshard_impl.h: Added DiscoverIndexesRecursive() declaration
- schemeshard_incremental_restore_scan.cpp: Implemented recursive discovery

Both issues validated and confirmed as correct feedback.

…bles

Problem:
- Index impl table restore incremented impl table's AlterVersion
- Parent index metadata AlterVersion was not synchronized
- Caused 'schema version mismatch' errors during table queries

Root Cause:
- Used Parent().IsTableIndex() which returned false for index impl tables
- For index impl table path /Root/Table/Index/indexImplTable:
  - Parent().IsTableIndex() checks if parent PathType is TableIndex
  - This was incorrectly returning false

Solution:
- Changed check to dstTablePath.IsInsideTableIndexPath()
- IsInsideTableIndexPath() correctly detects tables inside index structures
- It skips the impl table level and checks if ancestor is a TableIndex
- Now correctly identifies index impl tables and creates AlterTableIndex

This ensures index metadata AlterVersion stays in sync with impl table.